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Abstract 


Counter modes have been defined for block ciphers such as the 
Advanced Encryption Standard (AES). Counter modes use a counter, 
which is typically assumed to be incremented by a single sender. 
This memo describes the use of counter modes when applied to the 
Encapsulating Security Payload (ESP) and Authentication Header (AH) 
in multiple-sender group applications. 
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1. Introduction 


The IP Encapsulating Security Payload (ESP) specification [RFC4303] 
and Authentication Header (AH) [RFC4302] are security protocols for 
IPsec [RFC4301]. Several new AES encryption modes of operation have 
been specified for ESP: Counter Mode (CTR) [RFC3686], Galois/Counter 
Mode (GCM) [RFC4106], and Counter with Cipher Block Chaining-Message 
Authentication Code (CBC-MAC) Mode (CCM) [RFC4309]; and one that has 
been specified for both ESP and AH: the Galois Message Authentication 
Code (GMAC) [RFC4543]. A Camellia counter mode [RFC5528] and a GOST 
counter mode [RFC4357] have also been specified. These new modes 
offer advantages over traditional modes of operation. However, they 
all have restrictions on their use in situations in which multiple 
senders are protecting traffic using the same key. This document 
addresses this restriction and describes how these modes can be used 
with group key management protocols such as the Group Domain of 
Interpretation (GDOI) protocol [RFC3547] and the Group Secure 
Association Key Management Protocol (GSAKMP) [RFC4535]. 


1.1. Requirements Notation 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. Problem Statement 


The Counter Mode (CTR) of operation [FIPS.800-38A.2001] has become 
important because of its performance and implementation advantages. 
It is the basis for several modes of operation that combine 
authentication with encryption, including CCM and GCM. All of the 
counter-—based modes require that, if a single key is shared by 
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multiple encryption engines, those engines must coordinate to ensure 
that every Initialization Vector (IV) used with that key is distinct. 
That is, for each key, no IV value can be used more than once. This 
restriction on IV usage is imposed on ESP CTR, ESP GCM, and ESP CCM. 
In cryptographic terms, the IV is a nonce. (Note that CBC mode 
[RFC3602] requires IVs that are unpredictable. CTR, GCM, GMAC, and 
CCM do not have this restriction.) 


All ESP and AH transforms using a block cipher counter mode have a 
restriction that an application must not use the same key, IV, and 
Salt values to protect two different data payloads. Notwithstanding 
this security condition, block cipher counter mode transforms are 
often preferred because of their favorable performance 
characteristics as compared to other modes. 


Each of the block cipher counter mode transforms specify the 
construction of keying material for point-to-point applications that 
are keyed by the Internet Key Exchange version 2 (IKEv2) [RFC5996]. 
The specified constructions guarantee that the security condition is 
not violated by a single sender. Group applications of IPsec 
[RFC5374] may also find counter mode transforms to be valuable. Some 
group applications can create an IPsec Security Association (SA) per 
sender, which meets the security condition, and no further 
specification is required. However, IPsec can be used to protect 
group applications known as Many-to-Many Applications [RFC3170], 
where a single IPsec SA is used to protect network traffic between 
members of a multiple-sender IP multicast application. Some Many-to- 
Many Applications are comprised of a large number of senders, in 
which case defining an individual IPsec SA for each sender is 
unmanageable. 


3. IV Formation for Counter Modes with Group Keys 


This section specifies a particular construction of the IV that 
enables a group of senders to safely share a single IPsec SA. This 
construction conforms to the recommendations of [RFC5116]. A 
rationale for this method is given in Appendix A. In the 
construction defined by this specification, each IV is formed by 
concatenating a Sender Identifier (SID) field with a Sender-Specific 
IV (SSIV) field. The value of the SID MUST be unique for each 
sender, across all of the senders sharing a particular Security 
Association. The value of the SSIV field MUST be unique for each IV 
constructed by a particular sender for use with a particular SA. The 
SSIV MAY be chosen in any manner convenient to the sender, e.g., 
successive values of a counter. The leftmost bits of the IV contain 
the SID, and the remaining bits contain the SSIV. By way of example, 
Figure 1 shows the correct placement of an 8-bit SID within an 
Initialization Vector. 
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0 1 2 3 
0123456789012345678901234567890421 
tat—tatHtat—tatatataitatatatata ta tata t-tatHtat-t-t-t-4+-4+-4+-4+-4+-+-! 
! SID ! ! 
+-+-+-+-+-+-+-+-+ SSIV ! 
l l 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +H 


Figure 1. IV with an 8-bit SID 


The number of bits used by the SID may vary depending on group 
policy, though for each particular Security Association, each SID 
used with that SA MUST have the same length. To facilitate 
interoperability, a conforming implementation MUST support SID 
lengths of 8, 12, and 16 bits. It should be noted that the size of 
the SID associated with an SA provides a trade-off between the number 
of possible senders and the number of packets that each sending 
station is able to send using that SA. 


4. Group Key Management Conventions 


Group applications use a Group Key Management System (GKMS) composed 
of one or more Group Controller and Key Server (GCKS) entities 
[RFC3740]. The GKMS distributes IPsec transform policy and 
associated keying material to authorized group members. This 
document RECOMMENDS that the GKMS both allocate unique SIDs to group 
members and distribute them to group members using a GKM protocol 
such as GDOI or GSAKMP. The strategy used by the GKMS does not need 
to be mandated in order to achieve interoperability; the GKMS is 
solely responsible for allocating SIDs for the group. Allocating 
SIDs sequentially is acceptable as long as the allocation method 
follows the requirements in this section. 


The following requirements apply to a GKMS that manages SIDs. One 
example of such a GKMS is [GDOI-UPDATE]. 


o For each SA for which sender identifiers are used, the GKMS MUST 
NOT give the same sender identifier to more than one active group 
member. If the GKMS is uncertain as to the SID associated with a 
group member, it MUST allocate it a new one. If more than one 
entity within the GKMS is distributing sender identifiers, then 
the sets of identifiers distributed by each entity MUST NOT 
overlap. 
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o If the entire set of sender identifiers has been exhausted, the 
GKMS MUST refuse to allow new group members to join. 
Alternatively, the GKMS could distribute replacement ESP or AH 
Security Associations to all group members. When replacement SAs 
are distributed, the GKMS could also distribute larger SID values 
so that more senders can be accommodated. 


o The GKMS SHOULD allocate a single sender identifier for each group 
member, and issue this value to the sender for all group SAs for 
which that member is a sender. This strategy enables both the 
GKMS and the senders to avoid managing SIDS on a per-SA basis. It 
also simplifies the rekeying process, since SIDs do not need to be 
changed or re-issued along with replacement SAs during a rekey 
event. 


o When a GKMS determines that a particular group member is no longer 
a part of the group, then it MAY re-allocate any sender identifier 
associated with that group member for use with a new group member. 
In this case, the GKMS MUST first delete and replace any active AH 
or ESP SAs with which the SID may have been used. This is 
necessary to avoid re-use of an IV with the cipher key associated 
with the SA. 


5. Security Considerations 


This specification provides a method for securely using cryptographic 
algorithms that require a unique IV, such as a block cipher mode of 
operation based on counter mode, in a scenario in which there are 
multiple cryptographic devices that each generate IVs. This is done 
by partitioning the set of possible IV values such that each 
cryptographic device has exclusive use of a set of IV values. When 
the recommendations in this specification are followed, the security 
of the cryptographic algorithms is equivalent to the conventional 
case in which there is a single sender. Unlike CBC mode, CTR, GCM, 
GMAC, and CCM do not require IVs that are unpredictable. 


The security of a group depends upon the correct operation of the 
group members. Any group member using an SID not allocated to it may 
reduce the security of the system. 


As is the case with a single sender, a cryptographic device storing 
keying material over a reboot is responsible for storing a counter 
value such that upon resumption it never re-uses counters. In the 
context of this specification, the cryptographic device would need to 
store both SID and SSIV values used with a particular IPsec SA in 
addition to policy associated with the IPsec SA. 
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A group member that reaches the end of its IV space MUST stop sending 
data traffic on that SA. This can happen if the group member does 
not notify the GKMS in time for the GKMS to remedy the problem (e.g., 
to provide the group member with a new SID or to provide a new SA), 
or if the GKMS ignores the notification for some reason. In this 
case, the group member should re-register with the GCKS and expect to 
receive the SAs that it needs to continue participating in the group. 


This specification does not address virtual machine rollbacks that 
may cause the cryptographic device to re-use nonce values. 


Other security considerations applying to IPsec SAs with multiple 
senders are described in [RFC5374]. 
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Appendix A. Rationale for the IV Formation for Counter Modes with Group 
Keys 


The two main alternatives for ensuring the uniqueness of IVs ina 
multi-sender environment are to have each sender include a Sender 
Identifier (SID) value in either the Salt value or in the explicit IV 
field (recall that the IV used as input to the crypto algorithm is 
constructed by concatenating the Salt and the explicit IV). The 
explicit IV field was chosen as the location for the SID because it 
is explicitly present in the packet. If the SID had been included in 
the Salt, then a receiver would need to infer the SID value for a 
particular AH or ESP packet by recognizing which sender had sent that 
packet. This inference could be made on the IP source address, if AH 
or ESP is transported directly over IP. However, if an alternate 
transport mechanism such as UDP is being used [RFC3948] (e.g., for 
NAT traversal), the method used to infer the sender would need to 
take that mechanism into account. It is simpler to use the explicit 
IV field, and thus avoid the need to infer the sender from the packet 
at all. 


The normative requirement that all of the SID values used with a 
particular Security Association must have the same length is not 
strictly necessary, but was added to promote simplicity of 
implementation. Alternatively, it would be acceptable to have the 
SID values be chosen to be the codewords of a variable-length 
prefix-free code. This approach preserves security since the 
distinctness of the IVs follows from the fact that no SID is a prefix 
of another; thus, any pair of IVs has a subset of bits that are 
distinct. If a Huffman code [H52] is used to form the SIDs, then a 
set of optimal SIDs can be found, in the sense that the number of 
SIDs can be maximized for a given distribution of SID lengths. 
Additionally, there are simple methods for generating efficient 
prefix-free codes whose codewords are octet strings. Nevertheless, 
these methods were disallowed in order to favor simplicity over 
generality. 


Appendix B. Example 


This section provides an example of SID allocation and IV generation, 
as defined in this document. A GCKS administrator determines that 
the group has one SA that is shared by all senders. The algorithm 
for the SA is AES-GCM using an SID of size 8 bits. 


When the first sender registers with the GCKS, it is allocated SID 1. 
The sender subsequently sends AES-GCM encrypted packets with the 
following IVs (shown in network byte order): 0x0100000000000001, 
0x0100000000000002, 0x0100000000000003, ... with a final value of 
OxO1LFFFFFFFFFFFFFF. The second sender registering with the GCKS is 
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allocated SID 2, and begins sending packets with the following IVs: 
0x0200000000000001, 0x0200000000000002, 0x0200000000000003, ... with 
a final value of Ox02FFFFFFFFFFFFFF. 


According to group policy, the GCKS may later distribute policy and 
keying material for a replacement SA. When group senders begin 
sending AES-GCM packets encrypted with the new SA, each sender 
continues to use the SID value previously allocated to it. For 
example, the sender allocated SID 2 would be sending on a new SA with 
IV values of 0x0200000000000001, 0x0200000000000002, 
0x0200000000000003, ... with a final value of Ox02FFFFFFFFFFFFFF. 
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